SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / program / 522 / okami12 / doc / okami.doc < prev next >

Wrap

Text File | 1991-04-17 | 59.6 KB | 1,377 lines

=============================================== @(#) OKAMI SHELL VERSION 1.2 - BENUTZERANLEITUNG =============================================== Stand: 25.12.90 BITTE ERST DIE DATEI README LESEN! ---------------------------------------------------------------------------- EINFÜHRUNG Die Okami-Shell ist ein (weiterer) Versuch, auf dem Atari ST so etwas wie Unix-Gefühle aufkommen zu lassen. Das Programm wendet sich an alle, die die Möglichkeiten eines Kommandointerpreters denen des Desktops vorziehen. Die Shell ist vor allem beim Betrieb mit einer Festplatte ausgesprochen nützlich. Obwohl es schon einige Programme dieser Art gibt, gibt es gewichtige Gründe, die Okami-Shell zu benutzen und sich durch die folgende Anleitung zu arbeiten. Die Okami-Shell ist einer der Unix-orientierten Kommandointerpreter für den ST, der die Unix-Möglichkeiten der Ein/Ausgabe-Umleitung und des Pipelinings auch für die internen (in der Shell eingebauten) Kommandos ermöglicht. Die Ein/Ausgabe-Umleitung ist die Möglichkeit, die Standard-Ausgabe eines Programmes, d.h. alles, was mit printf etc. ausgegeben wird und normaler- weise auf dem Bildschirm landet, sowie die Standard-Eingabe in eine Datei oder zu einem Gerät (z.B. zum Drucker) umzuleiten. Die Umleitung funktio- niert unter TOS mit dem GEM-Desktop a) nur bei TTP-Programmen, weil man nur bei diesen die Möglichkeit hat, eine Kommandozeile einzugeben, und b) nur bei Programmen, deren Compiler die Umleitung unterstützen. Die Okami- Shell führt die Umleitung selber durch, wodurch auch Programme, die ihre Kommandozeile nicht beachten (z.B. solche, die mit dem Pd-Modula-2-System erstellt wurden), umgeleitet werden können. Die Okami-Shell kann allerdings noch etwas mehr: sie ist ein universelles Utility, mit dem man nicht nur Programme starten, sondern auch Programme schreiben und debuggen usw. kann. Als Bonbon hat sie einen eingebauten UPN- Rechner mit ca. 80 Funktionen. Bei der Programmierung einer Shell oder eines Kommandointerpreters steht man immer vor der Frage, ob man für die in der Shell eingebauten Kommandos Unix-, MS-DOS- oder eine selbstausgedachte Schreibweise benutzen soll, d.h. ob man die Kommandos ls oder dir, mv oder rename, cp oder copy nennen soll oder ob man sich eingene Kommandonamen ausdenkt. Die Okami-Shell ist an den Unix-Bezeichnungen orientiert, genauer gesagt an dem Unix-Derivat AIX, das z.B. auf dem IBM RT PC 6150 läuft. Natürlich müssen bei soetwas Abstriche gemacht werden, der Atari ist schließlich keine Unix-Maschine, und eine Shell ist kein Betriebssystem. Wer sich in Unix einigermaßen auskennt, kann mit der Okami-Shell wahrschein- lich sofort loslegen. Die folgende Anleitung stellt die Verwendung der Shell dar, die Erklärung der internen Kommandos mit Syntax befindet sich in der Datei commands.doc. Um die vielen Versionen der Shell unterscheiden zu können, gibt das Kommando "ver" eine Information mit Versionsnummer und Kompilierungszeitpunkt aus. Zur Interpretation der Versionsnummer siehe tricks.doc. ---------------------------------------------------------------------------- SUPPORT Die Okami-Shell ist public domain, d.h. sie kann von jedermann benutzt und weitergegeben werden, ohne daß jemand etwas dafür zu bezahlen hat. Trotz- dem bitte ich um Rücksendung der Software-Kontaktkarte, die nach Eingabe von "contact" von der Shell über den Hardcopydrucker ausgegeben wird. Über den Support ist es jederzeit und für jeden möglich: 1) die neueste Version der Shell zu bekommen, 2) konfektionierte Versionen zu erhalten, in denen die Systembeschränkungen (Anzahl der Variablen, Funktionen etc.) verändert sind. Wer also eine Version braucht, die bis zu 200 Variablen verwalten kann, kann eine solche bekommen. Außerdem können beliebige Kommandos ausgeblendet werden, um die Shell kleiner zu machen. Wer also z.B. den UPN-Rechner und das basep- Kommando nicht braucht, kann eine Shell erhalten, in der diese Kommandos nicht enthalten sind, die aber entsprechend kürzer ist. Es ist verboten, das Programm zu verkaufen oder es unter einem anderen Namen als meinem zu vertreiben. Wer irgendwelche Teile des Programms oder der Quellen in eigenen Programmen benutzen will, darf dies tun, solange mein Name im Programm und in der Dokumentation erwähnt wird. Die Datei "copying" enthält genaue Hinweise zum Kopieren und Weitergeben der Shell. Das Programm wird voll unterstützt, d.h. es wird dynamisch weiterentwickelt, und jeder Anwender kann bei mir jederzeit die neueste Version bestellen. Ebenso stehe ich bei Problemen und Wünschen zur Verfügung. Spenden sind natürlich auch willkommen, aber ausdrücklich nicht Vorraussetzung für den Erwerb von neuen Versionen, Anleitungen oder sonstigen Hilfen (dies ist allen Pd-Programmierern zur Nachahmung empfohlen). Der Quellcode kann ebenfalls bei mir bestellt werden (ca. 9000 Zeilen C). Als kleine Spende hätte ich hierfür allerdings gerne einen Taschenrechner - möglichst schön, am besten alt, notfalls ohne Batterien, aber bitte funktionsfähig. Dafür gibt es den vollständigen Quellcode mit allen verwen- deten Includefiles. (Was auch allen Programmierern zur Nachahmung empfohlen ist. Schließlich sind Quellcodes keine Staatsgeheimnisse, und vielleicht kann noch jemand etwas aus ihnen lernen.) (Nebenbei: um die Quellen der Okami-Shell zu kapieren, sollte man schon ziemlich gut C können und sich unter folgendem etwas vorstellen können: 1) Zeiger, 2) Arrays, 3) Zeiger auf Funktionen, 4) Arrays von Zeigern auf Funktionen, 5) Zeiger auf solche etc.) Meine Adresse: Wolfram Rösler Augustastr. 44-46 D-5100 Aachen Tel. 0241/504290 Wer irgendwelche Anregungen für weitere Versionen der Shell hat, kann sich damit jederzeit an mich wenden. Vergessen Sie jedoch nicht, daß die Okami- Shell ein Abkömmling der Bourne-Shell ist (im Gegensatz zu den meisten an- deren Shells wie Gulam und Mupfel, die die C-Shell simulieren). Alle An- fragen wegen Änderungen, die die Okami-Shell von dieser Identität weg und in die Nähe der C-Shell oder gar von MS-DOS bewegen würden (z.B. alias, pushd, popd oder MS-DOS-Features), sind von vornherein sinnlos. Statt alias gibt es die wesentlich leistungsfähigeren Shell-Funktionen, pushd und popd vermisse ich absolut nicht, und wer lieber MS-DOS als Unix hat, dem ist sowieso nicht zu helfen. ---------------------------------------------------------------------------- PROGRAMMFEHLER "Selbst der umsichtigste Programmierer kommt manchmal in Situationen, wo das Programm nicht richtig funktioniert." Texas Instuments, "Individuelles Programmieren" Handbuch zu TI 58/58C/59, 1977 Der Software-Support deckt die Beseitigung von Fehlern in der Shell ab. Wer einen Fehler findet, sollte also nicht die Okami-Diskette in die Ecke schmeißen und sich einer anderen Shell zuwenden (die hat nämlich auch Fehler), sondern mit einen Hinweis mit möglichst genauer Fehlerbeschreibung schicken. Wenn man eine Diskette und DM 1,70 Rückporto beilegt, bekommt man die korrigierte Version der Shell sobald wie möglich zurück. Natürlich kann ich keine Verantwortung für irgendwelche Schäden, die durch die Shell, ihre Anwendung oder die Unfähigkeit ihrer Anwendung verursacht werden, übernehmen. ---------------------------------------------------------------------------- LIEFERUMFANG Zur Okami-Shell gehören die folgenden Dateien: KERN: sh.ttp Das Haupt-Shellprogramm. msh.prg Die Microshell zum Starten als GEM-Programm. msh.inf Konfigurationsdatei zur Microshell. profile Konfigurationsdatei beim Start der Shell. help Textdatei mit Syntaxerklärungen. okami.pic Das Titelbild. EXTERNE KOMMANDOS: calc.sh Benutzerschnittstelle zum eingebauten UPN-Rechner. format.ttp Programm zum Formatieren von Disketten. gem.prg Programm zur Benutzung von Accessories. contact.sh Shellscript zum Ausdrucken der Kontaktkarte. print.sh Shellscript zum Ausdrucken von Dateien. print.tr Filtertabelle dazu. sed.ttp Der Streameditor. Siehe sed\sed.doc . showpic.sh Demo-Shellscript zur Anzeige von Bilddateien. QUELLEN: msh.c msh.prg (C) gem.lst gem.prg (GFA-Basic 2.0) format.c format.ttp (C) system.c Zum Einbinden der Shell in eigene Programme. (C) DOKUMENTATION: readme Grundeinführung für den Anwender. doc\*.* Anleitungen. SONSTIGES: okami.dbl Ein Icon mit dem Okami-Schriftzeichen zum Einbau in eine Icondesk-Datei. altur112.ttp Eine Überraschung für den Programmstart. sed\*.* Ein Ordner mit den Quellen, Anleitung und Beispiel- dateien zu dem Streameditor "sed". Alle ausführbaren Programme wurden mit dem Programm-Packer von Th. Quester und M. Fritze gepackt. sed.ttp und die Dateien im sed-Ordner sind Teil des Gnu-Betriebssystems. Sie unterliegen den Gnu-Lizenzbestimmungen und dürfen daher nur mit den Quellen weitergegeben werden. Über den Urheber der Datei altur112.ttp ist mir nichts bekannt, ich habe sie auf einer Pd-Diskette von 1987 gefunden. Ausgepackt ist sie übrigens über 22 KB groß. ---------------------------------------------------------------------------- RAM Die Shell benötigt ca. 150 KB an Laufzeitspeicher => lauffähig auch auf 512KB-Maschinen. Empfohlen werden allerdings 1 MB oder mehr. Massespeicher Für die zum Lauf notwendigen Dateien werden minimal ca. 120 KB benötigt. Mit allen Hilfsdateien (Microshell, Profile, sed,...) werden ca. 200 KB benötigt. Die Shell kann jedem Massespeicher betrieben werden. Für die Verwendung des Pipelinings ist es jedoch notwendig, daß auf einen Massespeicher (nicht notwendigerweise den, von dem die Shell gestartet wurde) geschrieben werden kann. Für diesen Zweck kann auch eine eigene kleine Ramdisk angelegt werden (16-32K). Bildschirm Läuft fehlerfrei in hoher und mittlerer Auflösung. Der Betrieb in niedriger Auflösung ist möglich, aber einige interne Kommandos gehen davon aus, das pro Zeile 80 Zeichen zur Verfügung stehen (z.B. df und hd). Die Be- nutzung dieser Kommandos kann dann zu Störungen in der Bildschirmausgabe führen. In keinem Fall kommt es jedoch zu einem Programmabsturz. Sollte mit jeder Farb- und Schwarzweiß-Emulation funktio- nieren. Geräte Die Shell unterstützt Maus, Drucker und die RS232-Schnitt- stelle. Es werden jedoch keine Geräte außer Bildschirm und Tastatur unbedingt benötigt (auch nicht die Maus). (Genau- genommen werden nicht einmal Bildschirm und Tastatur unbe- dingt benötigt.) Betriebssystem Die Shell wurde unter TOS 1.2 und 1.4 auf einem Atari 1040 ST entwickelt und ist "sauber" programmiert, d.h. es erfolgt kein Zugriff auf undokumentierte oder veränderliche System- adressen o.ä. Die Shell sollte daher mit jedem früheren und zukünftigen TOS zusammenarbeiten (abgesehen von Betriebs- systemfehlern.) Software Jedes TOS- und TTP-Programm kann von der Shell als externes Kommando aufgerufen werden. GEM-Programme können aufgerufen werden, wenn die Shell selber als GEM-Programm gestartet wird, was z.B. der Fall ist, wenn msh.prg zum Start der Shell benutzt wird. Zum Verändern der Konfigurationsdateien profile und msh.inf ist ein Ascii-Editor erforderlich. Ich empfehle Tempus oder den Pd-Editor Micro-Emacs. (Micro-Emacs ist über den Pd-Versand oder direkt bei mir er- hältlich.) ---------------------------------------------------------------------------- INSTALLATION Die Okami-Shell kann direkt von der Diskette gestartet werden. Siehe hierzu den folgenden Abschnitt. Ihre volle Effizienz entwickelt die Shell allerdings erst beim Einsatz von der Ramdisk oder Festplatte. Theoretisch kann die Shell auch auf einem Eprom installiert werden. INSTALLATION AUF RAMDISK Ich empfehle die selbstkomprimierende Maxidisk, da sie die optimale Speicher- ausnutzung garantiert. Für die Shell sollten mindestens 100 KB Maxidisk oder ca. 150 KB einer anderen Ramdisk zur Verfügung stehen. Wer genug Speicher hat, sollte die Ramdisk auf mindestens 200 KB konfigurieren. Für den vollen Betrieb der Shell sollten folgende Dateien (am besten in einen eigenen Ordner) auf die Ramdisk kopiert werden: sh.ttp profile msh.prg msh.inf help print.tr okami.pic commands.doc <------ aus dem Anleitungsordner altur112.ttp in einem Unterordner namens bin: *.sh format.ttp gem.prg sed.ttp callsed.sh <------ aus dem Ordner "sed" ship.exe <------ für Festplattenbenutzer: das ship.prg der Harddisk-Utility-Disk Wer seine Kontaktkarte bereits abgeschickt hat, braucht die Datei contact.sh nicht. Die Datei help wird für das Shell-Kommando "help" benutzt; wer diese Datei ausdruckt und neben den Rechner legt, kann sich den Platz auf der Ramdisk ebenfalls sparen. Dasselbe gilt für commands.doc, das außerdem ziemlich viel Platz beansprucht. Die Dateien msh.prg und msh.inf gehören zusammen und werden zum Start der Shell als GEM-Programm benutzt. Wer von der Shell keine GEM-Programme starten will, braucht diese Dateien nicht. Auf die externen Kommandos wie gem und format kann man natürlich auch verzichten, nur muß man dann u.U. etwas häufiger ins Desktop zurück. print.tr gehört zu print.sh. Wer nichts drucken will, kann auch darauf verzichten. Den Streameditor sed können sowieso nur absolute Unix-Gurus bedienen, also braucht man auch sed.ttp und callsed.sh nicht unbedingt. Wer nicht bei jedem Systemstart das Titelbild sehen möchte, kann die Datei okami.pic umbenennen oder löschen. Dasselbe gilt für altur112.ttp. Auch auf profile kann man verzichten, allerdings wird die Shell dann mit den eingebauten Voreinstellungen initialisiert. => Die einzige Datei, die man wirklich braucht, ist sh.ttp. INSTALLATION AUF FESTPLATTE Bei Verwendung der Okami-Shell mit einer Festplatte kommt echtes Unix-Feeling auf, vor allem wenn man die Shell nach dem Systemstart automatisch starten läßt (ich empfehle zum Autostart: TOS 1.0 den Autostarter aus dem Data Becker-Buch "Die besten Tips&Tricks für Atari ST", S. 24ff. TOS 1.2 den Autostarter "startgem.prg", der zu Superboot 6.0 gehört, siehe PD-Journal 9/90, S. 43ff. >= TOS 1.4 msh.prg im Desktop als Autostart-Applikation anmelden) Mit einigen Tricks, die im folgenden erklärt werden, kann man sich z.B. bei jedem Start der Shell Datum und Uhrzeit des letzten Systemstarts ausgeben lassen oder das aktuelle Arbeitsverzeichnis so einstellen, wie man die Shell zuletzt verlassen hat. Außerdem kann man alle Programme, die man auf der Festplatte hat, per Name starten lassen, egal in welchem Verzeichnis man sich gerade befindet, und es werden sogar alle RSC-Dateien gefunden. Man tippt also z.B. ein: edit datei.txt und es erscheint der Editor mit der Datei datei.txt, egal wo im Dateisystem der Editor sich befindet. Für die Shell sollte ein eigener Ordner eingerichtet werden, in den die oben unter INSTALLATION AUF RAMDISK aufgeführten Dateien kopiert werden. Außerdem ist es sinnvoll, eine kleine Ramdisk (16-32K) anzulegen und die Pipe-Operationen über diese laufen zu lassen. Siehe dazu weiter unten. Wenn man sich die Anleitungen der Shell auf die Festplatte kopiert, braucht man die Datei commands.doc nicht noch einmal in den Shell-Ordner zu kopieren. Dann muß allerdings der Dateiname von commands.doc in der Shell-Variablen HELPFILE gespeichert werden. Siehe dazu weiter unten. Wer sich sein Desktop mit Icondesk von Stefan Becker verschönert hat, kann die Icon-Datei okami.dbl direkt in die icons.img-Datei einbauen. INSTALLATION IM COOKIE-JAR Der Cookie-Jar ist eine Möglichkeit des Betriebssystems, mit der installierte Programme dem System ihre Anwesenheit nebst Versionsnummer mitteilen können. Der Cookie-Jar wird erst ab TOS 1.6 vom Betriebssystem selber benutzt, kann aber bei allen früheren TOS-Versionen auch von Programmen installiert werden. Die Okami-Shell trägt sich unter der Kennung "OkSh" in den Cookie-Jar ein. Vorher installiert sie einen solchen, falls noch keiner vorhanden ist. Die Versionsnummer ist auf zwei Bytes aufgeteilt, bei Version 1.2 steht eine 2 im niedrigsten und eine 1 im nächsthöheren Byte. Mit dem internen Kommando cookie kann der Cookie-Jar ausgelesen werden. Siehe hierzu commands.doc. ---------------------------------------------------------------------------- START DER SHELL a) Direkt Die Shell befindet sich in der Datei sh.ttp. Diese Datei kann vom Desktop aus per Doppelklick gestartet werden. In der folgenden Eingabebox kann man folgendes eintragen: * Ein Shell-Kommando, dann wird dieses Kommando ausgeführt und die Shell wird beendet, d.h. nach der Ausführung erscheint sofort wieder das Desktop. * Man läßt die Eingabezeile leer, dann wird die Shell im Dialog- modus gestartet, d.h. es erscheint ein Dollarzeichen als Prompt, hinter dem dann alle Shellkommandos eingegeben werden können. Beendet wird die Shell durch Eingabe von "exit" oder durch Druck auf Ctrl V bei der Kommandoeingabe. * Man gibt ein Minuszeichen ein, dann startet die Shell ebenfalls im Dialogmodus, aber vorher wird festgestellt, ob sich im aktuellen Verzeichnis (i.d.R. das, in dem sich sh.ttp befindet) eine Datei namens "profile" befindet. Ist dies der Fall, so wer- den aus dieser Datei Shell-Kommandos gelesen und ausgeführt. Mit dieser Möglichkeit kann die Shell beim Start konfiguriert werden. Diese Art, die Shell zu starten, heißt in Unix-Manier "Login- Shell". Es ist auch möglich, erst ein Minuszeichen und dann ein Kommando einzugeben, z.B. - ls -l *.c Dann wird erst das Profile gestartet, dann das Kommando ausgeführt und die Shell beendet. Wenn die Parameterzeile mit -c beginnt, also z.B. -c df a: c: , dann wird das -c ignoriert. Dies ist z.B. zum Aufruf der Shell aus dem PD-Editor Micro-Emacs nützlich. Anmerkung: Über den Software-Support kann eine Shell bezogen werden, die sich im Hinblick auf das übergebene Minuszeichen genau andersherum verhält, d.h. sie initialisiert sich mit dem Profile immer, außer es wird ein Minuszeichen übergeben. b) Indirekt Die Shell kann indirekt von jedem Programm aus mit der GEMDOS-Funktion Pexec gestartet werden. Dies geschieht z.B. bei Verwendung der mitgelie- ferten system-Funktion oder beim Aufruf von der Microshell. Da die Shell den Environment-String benutzt, sollten Programme, die das nicht tun, als letzten Parameter von Pexec eine NULL übergeben (und nicht einen Leer- string - das ist ein GROSSER Unterschied.). Wenn der Shell dabei ein Parameterstring übergeben wird, so wird dieser als Kommando ausgeführt. Er darf mehrere (durch Semikolon getrennte) Kommandos und I/O-Umleitung enthalten. Der Kommandostring kann, muß aber nicht durch "-c" eingeleitet sein. Wenn die Shell als Login-Shell gestartet werden soll und es möglich sein soll, GEM-Programme von der Shell aus zu starten, muß die Shell mit der Microshell (msh.prg) gestartet werden. Dazu müssen folgende Voraussetzungen zutreffen: 1) Im selben Directory wie sh.ttp stehen die Dateien msh.prg und msh.inf. 2) Die Datei msh.inf enthält mindestens die folgende Zeile: sh.ttp - Dann wird die Shell nach Doppelklick auf msh.prg automatisch als Login-Shell gestartet. Es können alle GEM-Programme von der Shell aus ausgeführt werden. Siehe hierzu auch msh.doc. Wenn die Shell auf diese Weise vom Desktop aus gestartet wird, sollte das Profile die Zeile trap cursor -v enthalten. Dann wird nach dem Ende der Shell automatisch der Cursor abge- schaltet (auf dem Desktop stört er ziemlich). Siehe hierzu auch commands.doc. ---------------------------------------------------------------------------- KONFIGURATION Wenn der Shell als einziger Parameter ein Minuszeichen übergeben wird, sucht sie nach dem Start im aktuellen Verzeichnis eine Datei mit dem Namen profile. Wenn eine solche Datei vorhanden ist, wird sie wie ein Shellscript (siehe dazu weiter unten) ausgeführt. Das Profile kann eine Einschaltmeldung auf dem Bildschirm ausgeben und Shellvariablen wie z.B. das Prompt (PS1) setzen. Außerdem können die Shell-Flags eingestellt werden (siehe dazu das interne Kommando "set" in commands.doc). Das Profile kann alle Aktionen ausführen, die ein nor- males Shellscript auch ausführen kann. ---------------------------------------------------------------------------- KOMMANDOEINGABE a) Von der Tastatur Wenn die Shell im Dialogmodus gestartet ist, können nach dem Prompt (i.d.R. ein Dollarzeichen) Kommandos eingegeben werden. (Das mitgelieferte Profile stellt das Prompt um, so daß im Prompt immer das augenblickliche aktuelle Directory zu sehen ist.) Mit dem internen Kommando keydef kann jede beliebige Taste umdefiniert werden. Das bedeutet, daß alle der unten angeführten Tastenfunktionen ungültig werden können, wenn die jeweiligen Tasten redefiniert werden. Die einzigen Funktionen, die nicht umdefiniert werden können, sind ENTER und Ctrl Shift Undo. Für weitere Informationen siehe commands.doc zum Thema keydef. Bei der Eingabe werden folgende Sondertasten benutzt: Backspace das zuletzt eingegebene Zeichen wird gelöscht. Pfeil auf Es wird das zuletzt eingegebene Kommando ange- zeigt. Dieses kann mit ENTER übernommen oder mit Backspace editiert werden. Durch wiederholten Druck auf Pfeil auf wird das vorletzte Kommando angezeigt usw. Es werden maximal 100 Kommandos gespeichert (wer mehr braucht, benutze den Soft- ware-Support, um eine entsprechend angepaßte Version der Shell zu erhalten.) Diese Eigenschaft der Eingabe nennt man "History". Shift Pfeil auf Wie Pfeil auf, aber es wird die letzte Zeile aus der History angezeigt, die mit der bisherigen Eingabe übereinstimmt. Gibt man also ein "ls " und drückt Shift Pfeil auf, dann wird das letzte ls-Kommando zurückgeholt. Der Zeiger in der History-Liste steht dann hinter dieser Zeile, ein weiterer Druck auf Shift Pfeil Auf bringt also das vorletzte ls-Kommando zurück usw. Ctrl Pfeil auf Wie Pfeil auf gefolgt von einem Druck auf ENTER, es wird also das zuletzt eingegebene Kommando nicht nur angezeigt, sondern auch ausgeführt. Geht auch zusammen mit Shift. Pfeil ab Zeigt das nächste Kommando in der History-Liste an. Mit Pfeil auf und Pfeil ab kann man also in den in der History-Liste gespeicherten Kommandos blättern. Shift Pfeil ab Analog zu Shift Pfeil auf. Ctrl Pfeil ab Wie Pfeil ab gefolgt von einem Druck auf ENTER, analog zu Ctrl Pfeil auf. Pfeil links Wie Backspace. Pfeil rechts Das nächste Zeichen der vorigen Eingabe wird zurück- geholt. Siehe unten. Insert Speichert die aktuelle Position für Pfeil rechts. Siehe unten. Clr Home Die Eingabezeile wird gelöscht. Help Es wird eine Erklärung des eingegebenen Kommandos ausgegeben. Siehe unten. Ctrl Shift Undo Für diese Eingabezeile wird die Tasten-Redefinition ausgeschaltet. Die Eingabe verhält sich also so, als ob seit dem Start der Shell keine keydef-Kommandos aus- geführt worden wären. Die Funktion wird durch ein Klingelzeichen bestätigt. Control F Es erscheint eine Fileselect-Box, der ausgewählte Dateiname wird in die Eingabe übernommen. Das geht nur, wenn gon aktiv ist (siehe commands.doc zum Stichwort gon). Control P Es wird Hardcopy ausgeführt. Dies geschieht durch Auf- ruf der Shellfunktion "screensave". Die Voreinstellung dieser Funktion ist ein einfacher Aufruf des internen Kommandos "hardcopy", wodurch der Bildschirminhalt auf dem Drucker ausgegeben wird. In der Datei tricks.doc ist eine screensave-Funktion angegeben, durch die die Hardcopy in eine Datei geschrieben wird. Control V Die Shell wird beendet. Es können beliebige Ascii-Codes in der Schreibweise "^ooo" eingegeben werden, wobei ooo eine dreistellige Oktalzahl ist. Um z.B. ein Escape- zeichen in eine Eingabe einzubauen: echo Jetzt kommt ein Esc: ^033 das war das Esc Auf diese Weise können alle VT52-Sequenzen benutzt werden. Siehe auch "echo" in commands.doc. Beispiele zur Verwendung von Pfeil rechts und Insert: 1) Anzeige der Namen aller DOC-Dateien, danach Ausgabe derselben. Die Kommandofolge lautet: dir *.doc cat *.doc Nach der Eingabe von "dir *.doc" tippt man "cat" und drückt dann auf die Pfeil rechts-Taste: es erscheinen die weiteren Zeichen der vorigen Eingabe, also " *.doc". 2) Anzeige der Namen aller C-Dateien, danach Ausgabe der vollständigen Datei- liste, nach Dateidatum geordnet. Die Kommandofolge lautet: ls *.c ls -lt *.c Nach der Eingabe von "ls *.c" drückt man zweimal auf Pfeil rechts: es erscheint "ls". Dann drückt man Insert, um die Position zu speichert, tippt " -lt" und drückt dreimal auf Pfeil rechts, um die weiteren Zeichen der vorigen Eingabe zurückzuholen. *** VERSUCH MACHT KLUCH *** Zur Benutzung der Help-Taste: Mit der Help-Taste kann jederzeit, und zwar ohne die Eingabe zu stören, zu einem Kommando die entsprechende Anleitung aus der Datei commands.doc ange- zeigt werden. Will man z.B. eine Diskette formatieren, so tippt man das Kommando "format" ein und überlegt dann, wie die Parameter noch waren - dann hilft ein Druck auf Help, und es erscheint die Anleitung zu format. Anschließend kann die Eingabe fortgesetzt werden. Das funktioniert auch, wenn bereits Parameter nach format eingegeben worden sind. Wenn man die Help-Taste bei leerer Kommandozeile drückt, wird man nach dem zu erklärenden Kommando gefragt. Bei der Angabe des zu erklärenden Kommandos gelten die Regeln für erweiterte Wildcards, d.h. mit "r*" wird das erste Kommando erklärt, das mit r beginnt usw. Beispiel: $ format A: <HELP> Eingabe format - Formatieren von Disketten Ausgabe ..... (usw.) $ format A: * weiter gehts (In diesem Beispiel steht <HELP> für das Drücken der Help-Taste und * für die Cursor-Position am Ende. $ ist das Shell-Prompt.) Der Pfadname der Datei commands.doc muß in der Shell-Variablen HELPFILE ge- speichert sein. Die Voreinstellung ist $HOME\doc\commands.doc. Wenn die Vari- able HELPFILE nicht gesetzt ist, wird die Datei help.txt im aktuellen Directory benutzt. Anstelle von commands.doc kann auch jede andere Datei benutzt werden. Damit ein Kommando in der Datei erkannt wird, muß die Datei folgende Regeln er- füllen: 1) Vor dem Text, der das Kommando erklärt bzw. der zu dem Kommando ausge- geben werden soll, muß eine Zeile stehen, die mit fünf Minuszeichen beginnt. 2) Direkt nach dieser Zeile muß eine Zeile stehen, die mit dem Kommando beginnt. Das Kommando geht vom Anfang der Zeile bis (exkl.) zum ersten Nicht- Buchstaben (Buchstaben sind a-z und A-Z, keine Umlaute, kein ß). Danach können weitere Informationen stehen, die nicht beachtet werden. 3) Der auszugebene Text beginnt mit der unter 2) beschriebenen Zeile und geht bis zur nächsten Zeile, die mit fünf Minuszeichen beginnt (exkl.). Beispiel: ----- 1) ls - Anzeigen von Directories 2) 3) (Weitere Angaben) 4) 5) ----- 6) Bei der Eingabe von "ls <HELP>" werden die Zeilen 2) bis 5) ausgegeben. Natürlich kann man auch eine Kopie von commands.doc anfertigen und dort einige weitere beliebige Informationen eintragen, die unter entsprechenden Stichworten abgefragt werden können. Die Ausgabe erfolgt wie mit dem Kommando "pg". Siehe hierzu commands.doc. b) Aus einer Datei Es ist möglich, Dateien zu schreiben, die Shell-Kommandos enthalten und diese Dateien Kommando für Kommando von der Shell ausführen zu lassen. Solche Dateien werden als Shell-Scripts (oder in der MS-DOS-Welt als Batch-Dateien) bezeichnet. Ein Shell-Script kann wiederum weitere Scripts ausführen usw., wobei die Tiefe der Rekursion durch den zur Verfügung stehenden Speicher und die systembedingte Maximalanzahl offener Dateien begrenzt ist. Rekursive Shellscripts sind natürlich auch möglich. Für die Kommandos in Shell-Scripts gelten dieselben Regeln wie für Kommandos, die über die Tastatur eingegeben werden. Leider ist die Aus- führung von Shell-Scripts derjenige Punkt, an dem die Okami-Shell und die normalen Unix-Shells am weitesten auseinanderklaffen, da beim Aufruf eines Shell-Scripts unter Unix dieses i.d.R. nicht von der Shell selber ausgeführt wird, sondern die Shell startet sich selber nochmals, um das Script auszuführen (Subshell). Auf dem ST ist diese Vorgehensweise wegen des begrenzten Speichers nicht zu empfehlen, weswegen jedes Shellscript von der Shell selber ausgeführt wird. Dies hat Konsequenzen z.B. bei der Ein/Ausgabeumleitung von Shell-Scripts und den einem Script übergebenen Parametern. Außerdem kann jedes Script auf alle Shellvariablen der aufrufenden Shell zugreifen und diese verändern. Bei der Ausführung eines Shellscripts wird das Script erst vollständig in den Speicher geladen und dann im Speicher ausgeführt. Das liefert besonders bei der Ausführung von Diskette enorme Geschwindigkeitsvorteile. Genügend Speicher ist normalerweise immer vorhanden, wenn man bedenkt, daß Scripts i.d.R. kleine Dateien (3-5K) sind. Bei Shellscripts gibt es die Möglichkeit, Programmierstrukturen wie if und while zu benutzen, die bei Tastatureingabe wenig Sinn machen. Damit ist es in der Tat möglich, Shellscripts zu schreiben, die wie ein Programm einer höheren Programmiersprache laufen. Siehe hierzu showpic.sh und commands.doc. Es gibt vier Arten von Kommandos: 1) interne Kommandos, 2) externe Kommandos, 3) Shellfunktionen, 4) Kommentare. INTERNE KOMMANDOS Ein internes Kommando ist ein Kommando, durch das eine Funktion innerhalb der Shell ausgeführt wird, das also in der Shell eingebaut ist. Interne Kommandos werden durch Eingabe ihres Namens aufgerufen. EXTERNE KOMMANDOS Ein externes Kommando ist nicht in der Shell eingebaut, sondern in einer Datei auf einer Diskette, Ramdisk oder Festplatte vorhanden. Hierbei kann es sich sowohl um eine ausführbare Datei (.PRG, .TOS etc.) als auch um ein Shellscript handeln. Externe Kommandos können durch Eingabe des vollständigen Pfadnamens der entsprechenden Datei, aber auch durch Eingabe des Kommandonamens (des Dateinamens ohne Pfad und Extender). Die zugehörige Datei wird auf den Pfaden gesucht, die in der Shell-Variablen PATH gespeichert sind. Externe Kommandos können nur ausgeführt werden, wenn ihr Datei-Extender einem der in den Shell-Variablen XEXT und SEXT gespeicherten entspricht. (Es kann jedoch jede Datei, unabhängig vom Dateinamen, explizit als Shell- script oder Binärdatei ausgeführt werden, und zwar mit den Kommandos "." und "exec".) Siehe hierzu auch den Abschnitt über externe Kommandos in commands.doc. SHELLFUNKTIONEN Shellfunktionen sind Shellscripts, die resident im Speicher gehalten werden. Sie haben dieselben Eigenschaften wie Shellscripts und können deshalb auch genauso programmiert werden. Alles, was über die Verwendung von Shellscripts gesagt wird, gilt auch für Shellfunktionen. Jede Shellfunktion hat einen Namen, der bis zu 80 Zeichen lang sein darf. Groß- und Kleinschreibung wird unterschieden, d.h. "hallo" und "Hallo" sind zwei verschiedene Shellfunktionen. Es können bis zu 100 Shellfunktionen defi- niert werden. Bei der Ausführung haben Funktionen die oberste Priorität, kommen also noch vor den internen Kommandos. Es ist also möglich, interne Kommandos umzude- finieren, indem man eine Shellfunktion mit demselben Namen anlegt. Inner- halb dieser Funktion kann auf das ursprüngliche Kommando zugegriffen werden, indem man dem Kommando ein Ausrufezeichen (ohne Leerzeichen) vorstellt. Die Syntax einer Deklaration von Shellfunktionen ist: [Funktionsname] "(" Dateiname ")" (1) oder Funktionsname "()" (2) "{" {Zeilen des Funktionsrumpfes} "}" oder Funktionsname "()" (3) "{}" (1) In der ersten Fassung wird die angegebene Datei als Shellscript in den Speicher geladen und unter dem Namen der Funktion abgespeichert. Wenn kein Funktionsname angegeben ist, wird der Basisname des Dateinamens (ohne Ex- tender) als Funktionsname benutzt. In dieser Fassung entspricht die Shell- funktion also einem speicherresidenten Shellscript. Wenn die angegebene Datei eine ausführbare Programmdatei ist, wenn also ihr erstes Wort 0x601a ist, wird das Programm geladen und eine Shellfunktion erzeugt, die das Programm mit exec -x startet. Auf diese Weise ist es möglich, auch Binärprogramme resident im Speicher zu halten und ohne Disketten- oder Plattenzugriffe beliebig oft zu starten. ACHTUNG: Die Vorgehensweise dabei beruht auf der Fähigkeit der Gemdos-Funktion Pexec, Binärprogramme zu laden und erst zu einem späteren Zeitpunkt unter Angabe der Basepage-Adresse zu starten. Die Dokumentation von Atari zu diesem Feature ist kurz und eindeutig; sie lautet: "Finger davon". Nichtsdestoweniger funktioniert es, aber es besteht keine Garantie, daß es immer oder mit allen Betriebssystemversionen funktioniert. (2) In der zweiten Fassung wird die Funktion von der Tastatur oder dem Shellscript, in dem die Deklaration steht, gelesen. Wenn bereits eine Funktion mit dem angegebenen Namen existiert, wird sie umdefiniert. Wenn der Funktionsrumpf leer ist, wenn also die Zeilen mit { und } direkt auf- einander folgen, wird die Funktion gelöscht. In dieser Fassung wird die Eingabe verkürzt, d.h. Leerzeilen, Kommentar- zeilen und führende Leerzeichen werden nicht mit abgespeichert. (3) In der dritten Fassung wird die Funktion gelöscht. Die zweite und dritte Fassung erwarten also mehr als eine Zeile. Die weiteren Zeilen der Deklaration werden von der sog. "Sekundäreingabe" erwartet, also von dem Gerät oder der Datei, von der augenblicklich Kommandos gelesen werden (das ist nicht immer die Standardeingabe). Wenn es sich dabei um die Tastatur handelt, erscheint als Prompt der Inhalt der Shellvariablen PS2. ACHTUNG: In keinem Fall darf zwischen Funktionsname und der geöffneten Klammer ein Leerzeichen stehen!!! Beispiele: hallo(hallo.sh) initialisiert eine Funktion namens "hallo". Die Funktion entspricht dem Shellscript hallo.sh. hallo (hallo.sh) ruft das Kommando hallo mit dem Parameter (hallo.sh) auf, ist also KEINE Deklaration einer Shellfunktion! (c:/bin/test.sh) initialisiert eine Funktion aus der Datei c:/bin/test.sh. Da kein Funktionsname angegeben ist, wird der Basisname der Datei benutzt, es wird also die Shellfunktion "test" er- zeugt. (c:/bin/hallo.prg) lädt das Programm hallo.prg und erzeugt eine Shellfunktion namens hallo, die das geladene Programm startet. hallo hat dabei folgenden Funktionsrumpf: exec -lg c:/bin/hallo.prg 0x8f30a wobei 0x8f30a die beim Laden ermittelte Adresse der Basepage von hallo.prg ist. hallo() { echo Hallo, wie gehts? read _ echo Es freut mich, daß es Dir $_ geht. _= } definiert die Funktion hallo mit dem angegebenen Funktions- rumpf. Die Verwendung von Shellvariablen ist möglich; in diesem Fall wird die Variable _ (Underscore) benutzt, die für temporäre Verwendungen zur Verfügung steht. Diese Deklaration kann sowohl in einem Shellscript stehen als auch über die Tastatur eingegeben werden. Bei Tastatur- eingabe erscheint das Prompt $PS2. hallo() {} Die Shellfunktion hallo wird gelöscht. hallo() { } Dito. () (weder Funktions- noch Dateiname angegeben) ist ein Syntax- fehler. Mit dem internen Kommando "fcts" kann eine Liste sämtlicher Shellfunktionen erzeugt werden. Die Definition einer beliebigen Shellfunktion kann mit dem Kommando "type" ausgegeben werden. Siehe hierzu commands.doc. Es gehört zur Philosophie von Unix, daß man an der reinen Eingabe nicht erkennen kann, ob es sich bei dem eingegebenen Kommando um ein internes Kommando, eine ausführbare Datei, ein Shellscript oder eine Shellfunktion handelt. Um das herauszufinden, gibt es das interne Kommando type. Siehe hierzu commands.doc. KOMMENTARE Eine Eingabe gilt als Kommentar, wenn sie mit einem Doppelkreuz (#) beginnt oder wenn sie nur aus einer leeren Zeile besteht. Kommentare werden von der Shell nicht weiter beachtet und sind nützlich zum Dokumentieren von Shell-Scripts. Die Tastatureingabe von Kommentaren ist zwar möglich, aber nicht unbedingt sinnvoll. ERWEITERTE WILDCARDS Die Okami-Shell erlaubt für die Angabe von Dateinamen ein Wildcard-System, das weit über das von Gemdos gestellte hinausgeht. Die einzigen Gemdos- Wildcards sind * und ?, wobei ein ein Dateiname nur einen Stern enthalten darf, und den nur am Ende von Name oder Extender. Bei "**" gibt es Probleme, "*hallo*" liefert nicht alle Dateinamen, die "hallo" enthalten usw. Die erweiterten Wildcards der Okami-Shell orientieren sich an denen, die von der Original-Unix-Shell zur Verfügung gestellt werden. Es bedeuten: * beliebig viele, auch null, beliebige Zeichen. ? genau ein beliebiges Zeichen. [abcd] genau ein Zeichen, und zwar eins der in den Klammern stehenden. Es dürfen beliebig viele Zeichen angeführt sein. [a-g] genau ein Zeichen, und zwar a, b, ... oder g. Das Minuszeichen bedeutet also "bis". [~abc] genau ein Zeichen, und zwar ein beliebiges bis auf die Zeichen in den eckigen Klammern. Es dürfen beliebig viele Zeichen angeführt sein. Der Punkt zwischen Dateiname und Extender wird dabei wie jedes andere Zeichen behandelt, "*" paßt also auf alle Dateinamen und nicht nur auf die ohne Ex- tender. Beispiele: * alle Dateinamen. *.* alle Dateinamen, die einen Extender haben. *.? alle Dateinamen, deren Extender aus genau einem Zeichen besteht. *.[co] alle Dateinamen mit Extender .c oder .o. *.[~co] alle Dateinamen außer denen mit Extender .c und .o. [abcd]*[xyz] alle Dateinamen, deren erstes Zeichen a, b, c oder d und deren letztes Zeichen x, y oder z ist. Der Punkt, der den Extender einleitet (falls vorhanden), kann irgendwo dazwischen stehen. a[0-9] alle Dateinamen, die aus a, gefolgt von einer Ziffer bestehen, also a0, a1, ..., a9. ??[a-z][0-9] alle Dateinamen, die aus zwei beliebigen Zeichen, gefolgt von einem Buchstaben und einer Ziffer bestehen. Wenn das Shell-Flag w nicht gesetzt ist, sind die erweiterten Wildcards außer Kraft gesetzt. Die Shell benutzt dann nur die Wildcards, die von TOS zur Verfügung gestellt werden. Das Programm für den Vergleich mit erweiterten Wildcards stammt von Rich Salz und wurde 1986 geschrieben. Ich habe es aus einer Mailbox. FLAGS UND PARAMETER Jedem Kommando können Flags und Parameter übergeben werden. I.d.R. werden Parameter benutzt, um festzulegen, womit etwas getan werden soll, und die Flags legen fest, wie es getan werden soll. Die Shell teilt die Eingabezeile in Worte auf. Worte werden durch Whitespace- Zeichen (Leerzeichen, Tab, Formfeed) getrennt. Durch doppelte (") oder ein- fache (') Anführungszeichen können auch Whitespace-Zeichen in Worten benutzt werden, z.B. ist a b c d vier Worte, während "a b c d" nur ein Wort ist. Einfache Anführungszeichen verhindern außerdem jede Art von Interpretation, d.h. innerhalb von einfachen Anführungszeichen werden * keine Shellvariablen expandiert * keine Slashes zu Backslash umgeformt * keine Escape-Sequenzen (beginnent mit ^) interpretiert . Es ergibt also $HOME den Inhalt der Shell-Variablen HOME und '$HOME' den String $HOME. Externen Kommandos werden alle übergebenen Flags und Parameter als Kommando- zeile übergeben. Alle exportierten Shell-Variablen werden den externen Kommandos im Environment übergeben. Das Betriebssystem limitiert die Länge der Kommandozeile auf maximal 128 Zeichen. Den internen Kommandos können beliebig viele Flags und Parameter überge- ben werden, allerdings ist für die meisten Kommandos nur eine beschränkte Anzahl von Parametern sinnvoll. Die Flags der internen Kommandos werden durch ein Minus- oder Pluszeichen eingeleitet. Näheres siehe commands.doc. Die Shell benutzt eine Reihe eigener Flags, die mit dem internen Kommando set eingestellt werden können. Siehe hierzu commands.doc. VERKETTETE KOMMANDOS Kommandos können in einer Zeile durch Semikolon getrennt angeführt werden. Die Kommandos werden von links nach rechts ausgeführt. Wenn eine eingegebene Zeile mit einem Dach (^) endet, wird anstelle des Daches die Fortsetzung der Zeile von der Sekundäreingabe eingelesen. Das entspricht dem Backslash in Unix. Beispiel: ec^ ho ha^ l^ lo entspricht "echo hallo". Dabei kann diese Eingabe sowohl von der Tastatur als auch aus einem Shellscript oder einer Shellfunktion stammen. ---------------------------------------------------------------------------- SHELLVARIABLEN Eine besondere Art von internem Kommando ist die Zuweisung eines Wertes an eine Shellvariable. Alle Shellvariablen sind Stringvariablen. Der Name einer Shellvariablen kann in beliebiger Reihenfolge Buchstaben, Ziffern und Under- scores (_) enthalten. Beschränkungen: Maximalanzahl der Shellvariablen: 100 Maximallänge des Variablennamens und -Wertes: unbeschränkt (80 relevante Stellen) Wer damit nicht auskommt, benutze den Software-Support, um eine Version der Shell mit größeren Kapazitäten zu erhalten. Jede Shell-Variable hat einen Status, der aus beliebigen (auch null) der folgenden Eigenschaften besteht: USR (User) Die Variable wurde vom Benutzer angelegt oder verändert. SYS (System) Es handelt sich um eine Systemvariable, die von der Shell verwaltet wird. Hierzu gehören z.B. die Positionsparameter $0, $1..., $#, $? usw. R/O (Read-Only) Der Wert der Variablen darf nicht verändert und die Variable darf nicht gelöscht werden. EXP (Export) Die Variable befindet sich im Environment. Die Eigenschaften USR und SYS können nicht beeinflußt werden. Die Eigen- schaften R/O und EXP können mit den Kommandos readonly und export gesetzt und gelöscht werden. Siehe hierzu commands.doc. DEKLARATION Shell-Variablen brauchen nicht deklariert zu werden. ZUWEISUNG Die Zuweisung eines Wertes an eine Shell-Variable geschieht durch eine Eingabe der Form Variable=Wert z.B.: NAME=Okami-Shell Es wird der String "Okami-Shell" der Shellvariablen NAME zugewiesen. In Unix ist es üblich, Shell-Variablen in Großbuchstaben zu schreiben, es sind allerdings auch Kleinbuchstaben möglich. NAME und Name sind zwei unterschiedliche Variablen. Auf die folgende Weise kann einer Variablen ein leerer Wert zugewiesen werden: Variable="" Der Wert der Variablen wird also gelöscht, aber die Variable selber bleibt bestehen. Außerdem können die internes Kommandos "read", "fsel" und "mouse" zur Zuwei- sung von Eingaben an Shellvariablen benutzt werden. Siehe hierzu commands.doc. BENUTZUNG Der Wert einer Shell-Variablen kann durch Angabe des Variablennamens mit vorgestelltem Dollar-Zeichen angegeben werden. In einer Eingabezeile der Shell werden erst alle Variablen zu den betreffenden Werten expandiert, bevor die Zeile ausgeführt wird. Shell-Variablen, an die noch kein Wert zugewiesen wurde, werden als Leerstrings behandelt. Beispiele: NAME=Okami-Shell echo $NAME erzeugt die Ausgabe "Okami-Shell". NAME=Okami-Shell echo Der Name ist $NAME und nicht anders. erzeugt die Ausgabe "Der Name ist Okami-Shell und nicht anders." VAR1=$VAR2 weist der Variablen VAR1 den Wert der Variablen VAR2 zu. VAR1=VAR2 VAR3=VAR1 $VAR1=$VAR3 weist der Variablen VAR2 den String "VAR1" zu (ja, wirklich.) Es ist auch möglich, Shell-Kommandos an Variablen zuzuweisen und dann aus- führen zu lassen: CC=c:\compiler\cc.ttp $CC test.c ruft das Programm c:\compiler\cc.ttp mit dem Parameter test.c auf. LÖSCHEN Auf die folgende Weise werden Variablen gelöscht: Variable= Dies ist nicht zu verwechseln mit dem Löschen des Inhalts einer Variablen (siehe oben). Wenn hinter dem Gleichheitszeichen nichts steht, wird die Variable vollständig gelöscht und belegt danach keinen Platz mehr in der Variablentabelle. Dies ist notwendig, da die Shell nur über eine begrenzte Anzahl von Variablen verfügt. Besonders Shell-Scripts, die Variablen für lokale Zwecke benutzen, sollten diese Variablen nach der Benutzung wieder frei- geben. Beispiel: NAME= Die Shell-Variable NAME wird gelöscht. Beim Löschen verliert die Variable natürlich auch ihren Status. Um den Status zu erhalten, darf nur der Wert der Variablen gelöscht werden (NAME=""). Es ist möglich, eine Shellvariable zu benutzen, deren Name nur aus einem Underscore (_) besteht. Die Verwendung einer solchen Variablen für kurz- zeitige lokale Verwendungen ist z.B. in der Programmiersprache Prolog üblich. SAVECWD=$CWD cd c:\work\test .......................(weitere Kommandos) cd $SAVECWD Das aktuelle Verzeichnis (das stets in der Variablen CWD steht) wird in die Variable SAVECWD gesichert. Danach wird das aktuelle Verzeichnis geändert (mit dem internen Kommando "cd"), und es werden weitere Kommandos ausgeführt. Anschließend wird das aktuelle Verzeichnis wieder restauriert. Diese Technik sollte von allen Shellscripts benutzt werden, die das aktuelle Verzeichnis ändern. Unter Unix werden Shellscripts stets von Subshells ausgeführt, und das aktuelle Verzeichnis ist eine Eigenschaft eines Prozesses, weswegen Shellscripts das aktuelle Verzeichnis ändern können, ohne das aktuelle Verzeichnis der aufrufenden Shell zu beeinflussen. Unter TOS ist das aktuelle Verzeichnis eine Eigenschaft des jeweiligen Laufwerks, und das aktuelle Laufwerk ist eine globale Eigenschaft des gesamten Sys- tems. Die Okami-Shell benutzt keine Subshells, und daher kann jedes Shell- script das aktuelle Verzeichnis der Shell ändern, was in der praktischen Anwendung nicht immer erwünscht ist. Das umständliche Speichern und Restaurieren des aktuellen Verzeichnisses entfällt, wenn die Shell-Flags x und c gesetzt sind. Siehe hierzu das interne Kommando set in commands.doc. SYSTEMVARIABLEN Eine Reihe von Shellvariablen werden von der Shell selber angelegt und benutzt. Es ist teilweise möglich, die Werte dieser Variablen zu verändern. Die Systemvariablen sind: PS1 Das Eingabeprompt. Kann vom Anwender verändert werden (was normalerweise im Profile geschieht). Der Defaultwert ist " $ ". PS2 Das sekundäre Eingabeprompt. Erscheint z.B. bei der Eingabe von Shellfunktionen. Kann beliebig verändert werden, der Defaultwert ist "> ". LOGNAME Der Programmname ("Okami Shell"). Kann nicht verändert werden. VERSION Die Versionsnummer der Shell. Kann nicht verändert werden. TERM Der Rechnertyp, kann auf das individuelle Modell (z.B. "Atari 1040 STE" oder "Mega ST 4") eingestellt werden. Diese Einstellung erfolgt am besten in der Konfigurations- datei $HOME\profile. Der Defaultwert ist "Atari ST". Ist in der jetzigen Version der Shell noch ohne weitere Be- deutung. CWD Das aktuelle Verzeichnis. Wird nach jedem Wechsel des Verzeichnisses automatisch aktualisiert und sollte nicht von Hand verändert werden. (Durch eine Zuweisung an diese Variable wird das aktuelle Verzeichnis NICHT geändert.) HOME Das Verzeichnis, aus dem die Shell gestartet wurde (genauer gesagt das aktuelle Verzeichnis zum Zeitpunkt des Starts der Shell). Kann nicht verändert werden. SHELL Hier soll der vollständige Aufrufpfad des Shellprogramms eingetragen sein. Da die Shell diesen nicht mit völliger Sicherheit selber bestimmen kann, wird hier $HOME\sh.ttp eingetragen. Kann beliebig angepaßt werden, wenn diese An- gabe einmal nicht zutrifft. PAGELEN Die Anzahl der Zeilen auf dem Bildschirm. Wird von dem internen Kommando pg benutzt. Kann beliebig eingestellt werden. Die Defaulteinstellung ist 23. PIPDIR Das Laufwerk und der Pfad, auf dem die Hilfsdateien des Pipelinings erzeugt werden. Muß auf einem beschreibbaren Laufwerk (am besten auf einer Ramdisk) liegen. Die Default- einstellung ist $HOME. Kann beliebig verändert werden. NULL Der Name des Gerätes oder der Datei, an die die Ausgaben geleitet werden, die zum Null-Gerät (NULL:) umgeleitet werden. Kann verändert werden. Die Defaulteinstellung ist "PRN:" (paralelle Schnittstelle). Wer einen Drucker hat, sollte hier eine Datei z.B. auf der Ramdisk eintragen. Die Einstellung AUX: für die serielle Schnittstelle ist nicht möglich, da diese Schnittstelle von der Standard-Fehleraus- gabe belegt ist. XEXT Eine Liste von durch Kommata getrennten Extendern. Dateien mit einem der hier aufgeführten Extender können als Binär- programme gestartet werden. Die Defaulteinstellung ist ".prg,.tos,.ttp,.app". Die Punkte vor den Extendern müssen mit angegeben werden. Kann beliebig verändert werden. SEXT Eine Liste von durch Kommata getrennten Extendern. Dateien mit einem der hier aufgeführten Extender können als Shell- Scripts gestartet werden. Die Defaulteinstellung ist ".sh". Die Punkte vor den Extendern müssen mit angegeben werden. Kann beliebig verändert werden. GEXT Eine Liste von durch Kommata getrennten Extendern. Binär- Dateien mit einem der hier aufgeführten Extender werden als GEM-Programme gestartet, d.h. nicht direkt, sondern über die Shellfunktion gemexec gestartet. Siehe hierzu den Abschnitt über gemexec in commands.doc. Kann beliebig verändert werden. Wie in commands.doc erklärt, müssen die Extender nicht unbe- dingt denen von ausführbaren Programmdateien entsprechen. Die Defaulteinstellung ist .prg . PATH Eine Liste von durch Kommata getrennten Pfaden. Bei der Eingabe eines externen Kommandos ohne vollständige Pfadan- gabe wird die Datei auf den hier angegebenen Pfaden gesucht. Die Defaulteinstellung ist ".,..,$HOME,$HOME\bin". Kann be- liebg verändert werden. CDPATH Eine Liste von durch Kommata getrennten Pfaden. Beim Wechsel des aktuellen Arbeitsverzeichnisses mit "cd" wird, wenn der bei cd angegebene Pfad nicht existiert und nicht abso- lut angegeben ist, auf den in CDPATH gespeicherten Pfaden gesucht. Die Defaulteinstellung ist "..,\". Kann beliebig verändert werden. HELPFILE Der Name der Datei, aus der die Erklärungen, die bei Druck auf die Help-Taste ausgegeben werden, stehen. Die Default- einstellung ist "$HOME\commands.doc". Kann beliebig ver- ändert werden. COLUMNS Enthält die Anzahl der Textzeilen auf dem Bildschirm (24 oder 48). Wird nur von dem Kommando scr eingestellt und sollte nicht von Hand verändert werden. 0 Enthält bei Eingabe eines Kommandos den Namen des Kommandos und beim automatischen Aufruf der Funktion gemexec den voll- ständigen Pfad des aufzurufenden Programms. 1 Enthält den ersten Parameter der Eingabezeile. 2 Enthält den zweiten Parameter der Eingabezeile usw. # Enthält die Anzahl der Parameter der Eingabezeile. * Enthält die vollständige Eingabezeile. ? Enthält den Rückgabewert des zuletzt ausgeführten Kommandos. Nach dem Start der Shell werden Variablendefinitionen aus dem Environment gelesen und ausgeführt. Auf diese Weise können alle Variablen (auch LOGNAME, HOME usw.) geändert, aber keine gelöscht werden. ---------------------------------------------------------------------------- EIN/AUSGABE-UMLEITUNG 1) Für interne Kommandos Die Eingabe, Ausgabe und Fehlerausgabe jedes internen Kommandos kann auf einfache Weise in bzw. aus einer beliebigen Datei oder zu bzw. von einem Gerät umgeleitet werden. Folgende Umleitungsmöglichkeiten stehen zur Verfügung: < Datei Umleitung der Eingabe > Datei Umleitung der Ausgabe, die Datei wird vorher gelöscht >> Datei Anhängen der Ausgabe an die Datei 2> Datei Umleitung der Fehlerausgabe, die Datei wird vorher gelöscht 2>> Datei Anhängen der Fehlerausgabe an die Datei Anstelle von "Datei" können auch die folgenden Geräte angegeben sein: CON: Konsole (Default) PRT: parallele Schnittstelle (Drucker) AUX: serielle RS232-Schnittstelle (Modem) NULL: ignorieren Das Gerät NULL:, auch Null-Gerät genannt (in Unix: /dev/null), wird nicht vom Betriebssystem des ST unterstützt, sondern von der Shell simuliert. Der Zweck eines Null-Gerätes ist, die Ausgabe oder Fehlerausgabe eines Kommandos zu unterdrücken. Die Shell-Variable NULL gibt an, wo die Ausgabe, die an NULL: umgeleitet wird, tatsächlich landen soll. Die Voreinstellung ist die RS232-Schnittstelle, und dies sollte nur geändert werden, wenn diese Schnittstelle belegt ist. Im Notfall kann man als NULL eine reguläre Datei auf der Ramdisk oder Festplatte angeben. Wenn NULL die RS232-Schnittstelle ist, sollte man mit dem Kommando "rsconf -s19200" diese auf die höchstmögliche Übertragungsgeschwindigkeit einstellen, damit die Operationen mit dem Null-Gerät möglichst schnell gehen. Ein geeigneter Ort für diese Einstellung ist das Profile. Beispiel: rm *.dup löscht sämtliche dup-Dateien, gibt aber eine Fehlermeldung aus, wenn keine solchen Dateien vorhanden sind oder wenn sie schreibgeschützt sind. Um die Fehlermeldung zu unterdrücken, kann man stattdessen schreiben: rm *.dup 2>NULL: Dadurch werden die Fehlermeldungen an das Null-Gerät geleitet. (Nebenbei: bei Verwendung von rm -f *.dup werden auch keine Fehlermeldungen ausgegeben, allerdings werden damit auch schreibgeschützte Dateien gelöscht.) Wenn keine Umleitung angegeben ist, geht die Eingabe von der Tastatur und die Ausgabe und Fehlerausgabe zum Bildschirm, genauer gesagt zu der Standard-Ein- und -Ausgabe der Shell selber (die beim Start von sh.ttp angegeben werden kann). Pipelining Die Idee des Pipelining ist es, die Ausgabe eines Kommandos zur Eingabe des nächsten zu machen. So schreibt z.B. das memex-Kommando einen Speicher- bereich auf seine Ausgabe, und das hd-Kommando fertigt von seiner Eingabe ein Hexdump an. Mit dem Pipelining können beide Kommandos verbunden werden, d.h. man bekommt ein Hexdump eines Speicherauszuges. Um zwei Kommandos in einer Pipeline zu verbinden, wird zwischen sie ein senk- rechter Strich (|), auch Pipe genannt, gesetzt, z.B.: hd sh.ttp | pg Die Ausgabe des hd-Kommandos (ein langer Hexdump) wird zur Eingabe des pg- Kommandos, wodurch der Hexdump seitenweise angezeigt wird. Die Schreibweise a | b ist äquivalent zu: (a und b sind beliebige Kommandos incl. ihren Parametern) tmp=$PIPDIR\pip$$ a > $tmp chmod +h $tmp b < $tmp rm $tmp tmp= (mit zwei kleinen Unterschieden: 1) zum Bilden eines eindeutigen Dateinamens wird nicht $$, sondern ein anderer Zähler benutzt, und 2) es wird keine Shellvariable benutzt.) Dies ist ein wesentlicher Unterschied zu Unix, wo alle an einer Pipe be- teiligten Kommandos (Prozesse) gleichzeitig laufen. Eine Pipeline ist unter Unix eine Einrichtung des Betriebssystems, die von der Okami-Shell nur simuliert wird. (Wie gesagt, Okami ist eine Shell und kein Betriebs- system.) Das Laufwerk und der Ordner, auf dem die Pipe-Dateien erzeugt werden, kann mit der Shellvariablen PIPDIR eingestellt werden. Die Default-Einstellung beim Start der Shell ist $HOME. Dadurch bietet sich die Möglichkeit, die Pipe-Dateien auf ein schnelles Laufwerk zu legen, z.B. auf eine Ramdisk oder eine wenig benutzte Partition der Festplatte. VORSICHT: Wenn $PIPDIR auf einen nicht existierenden Ordner oder Laufwerk eingestellt ist, erscheinen anstelle von Pipe-Operationen nur Fehlermel- dungen der Form: Error: cannot open .....\pip3 (Anstelle von ...... steht der Inhalt von PIPDIR.) In diesem Fall wird keins der an einer Pipe beteiligten Kommandos ausge- führt. Die Pipe-Datei kann mit folgendem Kommando sichtbar gemacht werden: ls -a $PIPDIR\pip* | cat 2) Für externe Kommandos Theoretisch funktionieren sämtliche Ein/Ausgabe-Umleitungen inklusive der Pipeline auch mit externen Kommandos. In der Praxis jedoch erlauben nicht alle Programme diese Möglichkeit, z.B weil sie Tastatur und Bildschirm direkt über die entsprechenden Bios-Funktionen (Bconout etc.) ansprechen, die sich nicht umleiten lassen. Die Okami-Shell leitet die Ein/Ausgabe auf Gemdos-Basis um, was bedeutet, daß alle Programme, die für die Ein/Ausgabe Gemdos-Funktionen (Cconout etc.) benutzen, umgeleitet werden können. C-Programme, die die Standard-Streams stdin und stdout benutzen, werden normalerweise korrekt umgeleitet. GEM-Programme sind von vornherein gegen jede Art der Umleitung immun, da sie den Bildschirm über den entsprechenden GEM-Gerätetreiber ansprechen. ---------------------------------------------------------------------------- COMMAND SUBSTITUTION Die Okami-Shell bietet die Möglichkeit, die Ausgabe eines Kommandos in eine Kommandozeile einzubauen. Möchte man z.B. eine Ausgabe wie "Es sind ... Bytes frei" erzeugen, in die die Anzahl der freien Bytes (die mit dem Kommando mem ermittelt werden kann) eingebaut sind, dann kann die Ausgabe von mem auf fol- gende Weise in das echo-Kommando eingebaut werden: echo Es sind `mem` Bytes frei. Alles, was in einer Eingabezeile zwischen zwei Accent grave (`) steht, wird als Kommando betrachtet und ausgeführt. Die Ausgabe wird anstelle der in Accent grave stehenden Zeichenkette in die Eingabezeile eingesetzt. Dieses Verfahren wird als Command Substitution bezeichnet. Wenn die Ausgabe des Kommandos über mehrere Zeilen geht, wird nur die erste Zeile (also die Ausgabe bis zum ersten Zeilenende) benutzt. Als Zwischenspeicher für die Ausgabe des Kommandos wird eine Datei namens $PIPDIR/csubXXXX benutzt. XXXX ist hierbei eine laufende Nummer, und $PIPDIR ist das Laufwerk, über das auch die Pipelining-Operationen laufen. Diese Datei wird nach Verwendung gelöscht. Beispiele: Speichern der Shellflags: SET=`set -` Wiederherstellen mit: set $SET Anzeigen einer Datei, die in demselben Ordner liegt wie $FILE1, die aber denselben Basisnamen wie $FILE2 hat: cat `dirname $FILE1`/`dirname $FILE2` Löschen der ältesten Datei mit Nachfrage: rm -i `ls -t` ---------------------------------------------------------------------------- ENVIRONMENT Die Okami-Shell bietet die Möglichkeit, Definitionen von Shell-Variablen in das Environment zu übernehmen. Diese Definitionen werden dann allen gestarteten Programmen übergeben. Mit dem internen Kommando export können beliebige Shellvariablen in das Environment ausgenommen oder daraus ent- fernt werden. In der Basepage eines Programms steht ab Offset 0x2c die Adresse des Environment-Strings. Diese Adresse wird berechnet als: char *BaseAdr; char *EnvAdr; EnvAdr = *(char **)(BaseAdr+0x2c); BaseAdr ist die Adresse der Basepage (wird irgendwie vom Compiler zur Ver- fügung gestellt). EnvAdr ist dann die Adresse des Environment-Strings. Dieser String hat folgende Syntax: (EBNF, nicht C) EnvString ::= { VarDefinition } "\0" VarDefinition ::= VarName "=" VarWert "\0" Beispiel: "a=Variable a\0b=Variable b\0usw=undsoweiter\0\0" Es werden folgende Variablen gesetzt: a auf "Variable a" b auf "Variable b" usw auf "undsoweiter" Die Shell benutzt eine Funktion namens EnvInit(), mit der der Environment- String in einen Array von String-Adressen char *envp[] umgeformt wird. Dabei zeigen alle Elemente dieses Arrays in den Environment- String. Die Adresse eines solchen Arrays ist normalerweise (d.h. unter Unix) das dritte Argument der main()-Funktion. Wer an dieser Funktion interessiert ist, kann sich den Source-Code bestellen (Taschenrechner nicht vergessen). ---------------------------------------------------------------------------- GRÜßE 1) An die Firma GRP in Aachen, für lebenswichtige Kenntnisse in C und Unix. 2) Wer in Berlin wohnt und am Zen-Dojo in der Zossener Straße vorbeikommt, bestellt bitte Jonas und Wim viele Grüße von mir. 3) An Goofie Breuer, der mir für einen Spottpreis zwei Zauberkästen ver- hökert hat, auf denen "Atari 400" und "Atari 800" steht 4) Für die Begleitung in zahllosen Stunden voller Lust und Frust vor der flimmerfreien Flimmerkiste: Mike Oldfield, Little Richard, Bill Haley, Tommy Roe, Lesley Gore, Pat Boone, Elvis Presley, Chuck Berry, Del Shannon, Chris Montez, Billy Joe Royal, The Box Tops, The Cascades, Trini Lopez, Chris Andrews, Mary Hopkins, The Tremoloes, Bobby Vee, The Kinks, The Turtles, The Swinging Blue Jeans, Shane Fenton, The Piltdown Men, Helen Shapiro, Cliff Richard, The Cowsills, Jerry Lee Lewis, Melanie, Buddy Hollie, The Lovin' Spoonful, The Crystals, The Knickerbockers, The Crests, Every Mother's Son, The Shangri Las u.v.a.